-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[compiler-v2] Improved flush writes optimization #15718
Conversation
⏱️ 48m total CI duration on this PR
🚨 1 job on the last run was significantly faster/slower than expected
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
1603bb7
to
dedeb67
Compare
third_party/move/move-compiler-v2/src/pipeline/dead_store_elimination.rs
Show resolved
Hide resolved
third_party/move/move-compiler-v2/src/pipeline/flush_writes_processor.rs
Show resolved
Hide resolved
third_party/move/move-compiler-v2/src/pipeline/flush_writes_processor.rs
Outdated
Show resolved
Hide resolved
third_party/move/move-compiler-v2/src/pipeline/flush_writes_processor.rs
Outdated
Show resolved
Hide resolved
dedeb67
to
f64e874
Compare
@wrwg I believe I have addressed your comments, PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, as far as I understand.
I have a general question: what could go wrong if the flush processor has a bug? Is my understanding correct that the code would be weird (unnecessary flushing, for example), but it would not have a semantical effect?
23: MoveLoc[2](loc1: &mut u64) | ||
24: WriteRef | ||
25: Ret | ||
11: LdU64(2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an example where optimization makes the code size bigger?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, this and swap.opt.exp are the two minor regressions.
third_party/move/move-compiler-v2/src/pipeline/flush_writes_processor.rs
Show resolved
Hide resolved
@wrwg Yes, like I mentioned in the PR description, in the worst case (say, due to a bug), we mark additional/fewer temps to be flushed, then it can result in more StLoc-copy/moves than necessary, but the overall semantics itself should not change. The flush marks added by this pass can only cause a temp added to a stack to be flushed to a local right away, instead of retaining it on the stack. |
f64e874
to
14244c9
Compare
14244c9
to
0c69be6
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
0c69be6
to
45f6387
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
Description
Please note that we should not merge this PR until it undergoes comparison testing.
This PR contains a couple of optimizations, that together bring about 0.5% reduction in code size when compiling the aptos-framework and its dependencies (and compiler v2 produces 4% less code compared to compiler v1). They also address some transactions where v2 generated code took more gas than v1 generated code.
As an example, for the Move code below:
Compiler v2 currently produces:
With this PR, compiler v2 produces:
How Has This Been Tested?
third_party/move/move-compiler-v2/tests/variable-coalescing/swap.opt.exp
where we produce 2 additional instructions).Key Areas to Review
Type of Change
Which Components or Systems Does This Change Impact?